Columbia Kermit/kermit.zip/newsgroups/misc.19971216-19980424/000037_news@newsmaster….columbia.edu _Fri Jan 2 19:54:13 1998.msg

Internet Message Format | 2020-01-01 | 9KB

Return-Path: <[e-mail]>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
    by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id TAA18384
    for <[e-mail]>; Fri, 2 Jan 1998 19:54:13 -0500 (EST)
Received: (from news@localhost)
    by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id TAA15567
    for kermit.misc@watsun; Fri, 2 Jan 1998 19:54:12 -0500 (EST)
Path: news.columbia.edu!panix!logbridge.uoregon.edu!newsfeed.internetmci.com!206.20.110.210!news.slack.net!anon.lcs.mit.edu!nym.alias.net!mail2news
Date: Fri, 2 Jan 1998 16:50:00 -0700
From: [e-mail]
Message-ID: <[e-mail]>
Subject: K/2 Gotchas
Mail-To-News-Contact: [e-mail]
Organization: [e-mail]
Newsgroups: comp.protocols.kermit.misc
Lines: 224
Xref: news.columbia.edu comp.protocols.kermit.misc:8203


[This is being emailed to
[e-mail],
Rollin White, because I cite him as an information source in it (Thanks R.W..),

Glenn Currie because he wanted to keep in touch with what I'm up to.]

Now that I've got OS/2 fullscreen prompt access finally
(another story), I'm back to getting my scripts from MS-DOS Kermit
3.14 running on Kermit/2.  I'm presenting this stuff to document it for
myself, subject my own thinking and expriences to criticism from others
(and maybe learn something in the process), possibly save someone else
some grief, and maybe help sharpen the Kermit documentation.
Some of this might seem trivial, but could save
someone trouble if forwarned.

Things encountered:

1) Upgrading from 1.1.1.2 to 1.1.1.5 K/2 was complicated by a habit
(probably bad) of reading text files with an editor.  This has the
bad side effect of the occasional, accidental hitting of a key, or
maybe even adding my own notes.  The changed file would not get
updated with the upgrade patch.  After a little floundering around
everything was straightened out, going back to original files and
repatching.
A good personnal habit when installing
or patching an upgrade, if you insist on using an editor for file
viewing, might be to immediately

ATTRIB +r *.TXT *.DOC READ*.* /s

then *remembering* to

ATTRIB -r ... /s before patching.

(Probably better would be use a dedicated file viewing utility :-) )

2) My command files for exchanging email packages keep records
of what happens in a file in RAM disk.  At the end of the command file

run TYPE MAILTEMP.TMP >> C:\QWK\RECORD.LOG

is run to keep a permenant record of transactions.
This command ran on MS-DOS 3.14 but was causing problems when I
ran the command file on Kermit/2, with 'SYSxxxx   File name too long'
and such coming from the OS.  I finally tracked this down to the need to
change the command to

run TYPE MAILTEMP.TMP >> C:\\QWK\\RECORD.LOG

On MS-DOS Kermit 3.14, the single back slashes were permitted even though
the documentation clearly states that a double back slash should be used
when a back slash is desired where escaped substitution occurs.

3) When the command file got to the point where the mail package was being
generated, the BBS generates a stream of

^H|^H/^H-^H\^H|^H/^H-^H\^H...........

to indicate that things are not dead while the package is prepared.
This seemed to spas out the command file when run in Kermit/2, but
not MS-DOS Kermit.  The problem was eliminated when the input buffer was
increased from the default minimum size (256 bytes) to the maximum size
(65,536 bytes).  I noticed that there was a listing in BUGS.TXT that the
"input buffer was too small".  I don't think I have anything special about
the input buffer for my MK 3.14, so I conclude that either

a) the circular buffer works with MK 3.14 and not with K/2

or

b) the ^H's effectively erase characters already in the input buffer
   in MK 3.14 but not with K/2

Maybe it's some setting on my K/2 installation?


4)  Another problem was that a script seemed to stop, then fail on
'reinput' of a string that was obviously being recieved.  The real problem
turned out to be in an earlier 'input' command.  The Gotcha! in this case
was that besides going between versions of Kermit, there were two modems
involved - one external 33.6 USR Sportster and an internal 14.4 Zoom.
A shorter 'input' time setting that was just 'nice' because it ran faster in
MS-DOS Kermit with the 33.6 became essential in the Kermit/2 environment,
probably because everything is running faster and the longer wait threw
timings out of synch.  Look upstream in the script for problems on
'reinput'.

5)
Another problem was brought on when a dialup
script ran.  Everything went OK until I went to connect mode.
Then, as soon as anything was entered from the keyboard, K/2
left connect mode back to command mode, the session froze up,
the cursor went to lower left-hand corner and the session seemed to become
unkillable.  Any effort to stop the session would produce a message at the
bottom of the screen, something to the effect of
"!!! Recieved Kill Signal!!!", but the session lived on, hogging the
COM port, still locked up until reboot.
This problem seems to have been caused by starting to key in things
too soon after the login script ends - I've found that waiting a few
seconds after it ends before connecting, and a few more
afterward before doing things in the session seems to avoid the problem.
Afterwards, I can type as fast as possible and there doesn't seem to
be any problem.
Perhaps this is caused by some OS/2 keyboard setting I haven't figured
out yet.  The problem went unnoticed with scripts that conducted the entire
session, login to logout.   Some of the docs referenced
mysterious lockup problems usually traced to hardware causes.  Maybe
this experience will help with this.



6)  A while back, there was some discussion on comp.protocols.kermit.misc
about EXTPROC.  I later had some discussion about this with Rollin White,
president of So. CA OS/2 User's Group, (SCOUG, www.scoug.com)
professional OS/2 programmer, and one of the principal conspirators
of the Warpstock convention held in Oct. in Diamond Bar, CA (near L.A.).
He described this as an "outstanding issue" with OS/2, and provided
a C program that came with MAJORDOMO (as I recall) as one possible solution.
What happens is that after the *.CMD file invokes the EXTPROC specified
interpreter, the system then only searches the current directory
to find the text for the script it was invoked from.

Example:


EXTPROC   D:\K2\K2.EXE
echo
echo this is it, the successful test of EXTPROC
echo
quit
end

This will run when the sessions active directory is the same
as the CMD file is located in,
but will fail if executed from any other directory.

This will work from other directories as well as D:\K2 :


EXTPROC   D:\K2\K2.EXE   D:\K2\K2TESTQ.CMD
;                        AAAAAAAAAAAAAAAAA----This file's name
; if there were command line parameters, they'd need to
;  handled here
;  \&@[3] is typically where passed parameters start
;   besides the script file specification.
;
echo
echo this is it, the successful test of EXTPROC
echo
quit
end

Try this to get an idea of what is going on :

EXTPROC D:\K2\K2.EXE C:\OS2\SYSTEM\KTEST3.CMD
echo hello, world\13
echo \&@[0] \&@[1] \&@[2] \13\10
echo   \&@[3] \&@[4] \&@[5] \&@[6] \&@[7] \&@[8] \&@[9] \&@[10] \13\10
exit

(I suggest simply: [PROMPT]ktest3 a b c d e f g h i j k l <return>)
(By the way, double back slashes don't seem to correct anything on the
EXTPROC statement parameters, and will cause a problem here since
substitution of escaped coded isn't being conducted here.)

One possible solution/addition might be something along the lines
of PERL's  '-x' parameter:


@ECHO OFF
ECHO.
ECHO This is from the batch file...........
ECHO.
PERL -x c:\usr\bin\ptestq.bat
REM    Because of the '-x' switch, execution of this file will
REM    not start PERL execution till after the
REM        #![fully qualified file name for PERL]
GOTO REBATCH
#!c:\perl\bperl4x\perl-4.036\perl.exe
print "This is from the PERL script\n" ;
__END__
:REBATCH
ECHO.
ECHO This is from the batch file, AGAIN!!!...........
ECHO.

What EXTPROC (versus CALL or <ext. command name>) does is to
prevent any attempt for the further interpetation of the CMD file.
Something of a non-returning execution for a binary executable file.
On any other line then the first, it seems to cause the line
to be interpreted as a completely blank line.


Any way, everything is running fine now!  K/2
is definitly snappier then the DOS version, (I'm sold on 32 bit software)
and once a few problems
were ironed out the scripts are running fine.
This stuff has probably thrashed out a lot of portability issues
for myself, for the specific scripts involved.
I need to go back and install '3.15 on the DOS side of things,
and get back to trying it out under DOSEmu.




Regards,
Dallas E. Legan II
(562) 862 - 4854 ext. '*'
[e-mail]
[e-mail]
[e-mail]
[e-mail]

"But I found that the rulers were ordinary men, too, and frequently
as bewildered as I was."

                from "Solution Unsatisfactory"
                   by Robert A. Heinlein

I speak only for myself, and assume full responsibility for my statements.